Harden dependency audit baseline - #124
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcac16b127
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| publishes `@parity/product-sdk` 0.23.0, host 0.16.0, statement-store 0.6.5, | ||
| descriptors 0.10.0, and `polkadot-api` 3.0.0; upgrade remains a dedicated | ||
| compatibility task, not a casual lockfile bump. |
There was a problem hiding this comment.
Update the public page with the revised SDK roadmap
This changes the active Product roadmap by documenting newer SDK versions and deferring their upgrade to a dedicated compatibility task, but docs/index.html is absent from the commit. The public-facing roadmap therefore does not reflect the revised compatibility gate; update its Adaptive Product/current-gate narrative in the same change.
AGENTS.md reference: AGENTS.md:L50-L55
Useful? React with 👍 / 👎.
Outcome
This PR hardens the current dependency/audit baseline without changing Dotify runtime behavior or the Product DevNet SDK pins.
Issue and context
Refs #85 for Product SDK compatibility evidence. This is a maintenance slice before deeper blockchain payment work: reduce safe audit exposure now, and make the remaining SDK/toolchain drift explicit so it does not hide behind app feature PRs.
Architecture and key concepts
The change is intentionally split by surface:
web: fixes the vulnerablebrace-expansionoverride and refreshes safe lockfile versions already allowed by package ranges.services/api: refreshes Fastify/viem/transitive lockfile versions inside declared ranges, bringing the backend audit to zero.contracts/evm: refreshes Hardhat 2-line dev-tooling lockfile versions, while leaving the Hardhat 3 migration out of scope.No environment variables, hosted settings, contract addresses, CORS origins, or deploy commands change.
How it works
The frontend build still uses the pinned Product DevNet SDK baseline:
@parity/product-sdk0.20.1, host 0.15.1, statement-store 0.6.2, descriptors 0.8.0, andpolkadot-api1.23.3. This PR only applies safe patch/minor lock updates around that baseline and documents the newer official versions.The API keeps the same package ranges but resolves to patched transitive packages such as
fast-uri3.1.6,find-my-way9.9.0,ws8.21.0, andviem2.55.19.The contracts package remains on Hardhat 2.29.1. Forced audit remediation points to Hardhat 3 and newer plugin majors, so that migration is intentionally deferred.
Design decisions and tradeoffs
npm audit fix --force: it would move Product/PAPI and Hardhat paths through breaking changes with direct impact on Product Mobile, CDM/PAPI, and contract tooling.docs/index.html: no public capability, product positioning, or public roadmap promise changed.Security, failure, and operations
This reduces known vulnerable transitive packages where npm can do so safely. The PR does not claim a clean web audit:
deepmerge-tsandnanoidremain through Product/PAPI runtime dependencies and need a dedicated SDK compatibility pass. The contracts package is clean for--omit=dev, but full audit still reports Hardhat 2 dev-tooling findings.Operational docs now point to
docs/operations/dependency-security-status.mdas the evidence snapshot for this pass.Review guide
Suggested order:
web/package.jsonandweb/package-lock.json: verify the only package.json change isbrace-expansion5.0.9 and lockfile updates stay inside declared ranges.services/api/package-lock.json: verify this is a lockfile-only remediation and no env contract changes.contracts/evm/package-lock.json: verify it stays on Hardhat 2 and does not introduce a forced major migration.docs/operations/dependency-security-status.md: verify the residual risks and deferred migrations are honest.Verify carefully:
Validation
npm audit --audit-level=moderateinservices/apinpm audit --omit=dev --audit-level=moderateincontracts/evmnpm run testinservices/apinpm run buildinservices/apinpm run lintinwebnpm run test:unitinwebnpm run buildinwebnpm run build:product-devnetinwebnpm run test:e2e -- e2e/classic-unlock.spec.ts e2e/artist-publish.spec.tsinwebnpm testincontracts/evmKnown limitations and follow-ups
Pre-PR alignment check
Metadata checklist